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SECTION 1 
INTRODUCTION 


1 . 1 PURPOSE 

This document provides the functional- system definition for an on- 
line high density magnetic tape data storage system that can be 
implemented in a multi-purpose, multi-host environment, and satisfy 
the requirements of economical data storage in the range of 2 to 
50 billion bytes. 

Design assumptions shall be made to provide guidelines where spe- 
cific requirements do not exist. This document shall be a working 
document and updated as required. 
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1.2 CONCEPTS/OBJECTIVES 

Market and product surveys have shown that, currently, there are 
no systems available that meet the requirements identified in the 
originating statement of work. This document will define a stor- 
age device that can be modified or altered to comply with these 
requirements and shall be implemented as a major component within 
the on-line mass data, storage system. 

The device capabilities shall be demonstrated as soon as possible 
within the development phase of this activity. The mass storage 
system is to be implemented (minimal configuration) in the Building 
12 Central Computational Facility, which shall also serve as the 
test bed for the storage system. 

An analytical model of the mass storage system is to be developed 
to assist in performance evaluation during the feasibility studies 
and 'trade-off analysis. 

This activity shall also develop a system capable of accepting a 
sustained 10 megabit per second data thruput rate from the computer 
channel interface to the storage system. To accomplish this, a 
new technology, state-of-the-art device will be investigated for 
implementation into the data staging and buffering functions. An 
additional objective is to develop and implement a very low error 
rate data transfer between the mass storage system and the host 
computer channel. Methods to provide system error rates in order 
of 1 X 10”H bits are to be investigated. System analysis shall 
include trade-offs concerning redundant recording, error correction 
codes and component reliability. 


1-2 



JSC-10029 


1.3 APPLICABLE DOCUMENTS 

The following documents provide information related to this document. 

A. On-Line Mass Data Storage Requirements Doeument , Space 
Information Systems Operation, SISO-TN790, June 1975 

B. On-Line Mass Data Storage Engineering Order (EO) Number 
OOlP, Amendment Number 1, dated 11 September 1975 

» 

C. Univao 1108 and 1110 Exeo.-8 Mass Storage File System 
Performanoe Evaluation^ MTR-4586, June 1975 

D. Univao 1108 and 1110 Exec. -8 Mass Storage File Activity 
Analysis^ MTR-4577, December 1974. 

E. JSC-10038, Mass Storage System Simulation Planning 

F. JSC-10167, Quadruplex Reoord/Reproduoe Cartridge 
Storage Equipment Performanoe Specification 

G. JSC-10039, Reliability Evaluation of the General 
Electric BEAMOS Memory 

H. JSC-10040, Mass Storage System Error Rate Analysis 
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SECTION 2 

SYSTEM GENERIC REQUIREMENTS 


2.1 ■ INTRODUCTION 

System definition and design effort shall be directed toward a sys- 
tem capable of satisfying the following generalized requirements. 
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2 . 2 STORAGE 

A. Storage capacity should be expandable in increments up to 

50 billion bytes. As identified in the Section 5 of On-Line 
Mass Data Storage Requirements Document, SISO TN 790, data 
base users with requirements ranging from 2 to 50 billion 
bytes are currently unable to avail themselves of an econo- 
mical on-line mass storage system. The economics of imple- 
menting a currently available, minimal capacity trillion 
bit system precludes utilization for storage requirements 
in the range of 50 billion bytes and under. The cost of 
disk systems becomes significant in systems of 2 billion 
bytes and becomes a serious system determinant as the 
capacity approaches 3 billion bytes. 

A minimal system configuration may be implemented for test 
purposes but must be expandable at least to the 50 billion 
.byte capability. 

B. Storage media should provide for data erasure or modification. 
The file activity, in an on-line data storage system, exhi- 
bits properties similar to direct access storage devices 
(DASD) , such as; read old file, modify, create new file, 

save new file, and purge old files. These functions de- 
mand a storage media capable of supporting continuous 
record, read, and erase activities. 

It is not a mandatory requirement that the system be capable 
of "update in place"; however, the media should be reusable 
as old files are deleted, edited, and rewritten in another 
area or on another device. 

Storage media such as films, thermo plastics, metalized 
film strips, etc., that have read only or read mostly char- 
acteristics do not satisfy these requirements. 

C. Storage media should be modular with 10^ bytes per module 
(comparable capacities of large disk packs) in order to pro- 
vide a faster access time (to a randomly selected file) than 
IS normally exhibited by standard CCT's and existing video 
tape devices. It was deemed a necessary requirement that 
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.the recording media be partitional into small modules that 
can be positioned over the read/write heads faster than the 
normal search time of the lengthy serial devices. 

The module storage capacity must be comparable to that of 
presently available large disk pack capacities, (IBM 3330 
types) in the order of 100 megabytes. This is necessary 
to enable disk dump and load routines to place all data on 
one module rather than interrupting the routines to reposi- 
tion one or more modules of smaller capacity. 

D. Storage media should be self-contained and show no evidence 
of performance degradation when stored for long periods of 
time in a computer room environment. The storage media 
should be enclosed within its own modular container such as 
exists for the cartridge and disk pack systems. 

Degradation of performance is interpreted as loss of signal 
strength and excessive error rates when the data is retrieved' 
after being stored (without sustaining pox^er or refresh re- 
quirements) in a normal computer room environment for a 
period comparable to existing CCT storage requirements. 

The module should allow normal operator handling, i.e, 
loading, unloading and storing of the module without damage 
to the recorded information or impairment of the operation 
of the device itself. 

E. Storage modules should be replaceable from a library and 
interchangeable among like systems. As the size of the data 
base increases beyond that of the capacity of the on-line 
system, it is a necessary requirement that the storage 
modules be placed in an operational library and that index- 
ing, cataloging, and statusing functions be performed to 
provide a minimum response time to retrieval requests . 

One objection to some of the present high density recorders 
is incompatibility between systems such that data cannot be 
reliably reproduced when read on a different device. A 
requirement for this system is that data recorded within a 
storage module be transportable to another "like device” to 
be reproduced with the same fidelity as observed on the 
originating device. 
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The "like device” may be a redundant component of the ori- 
ginal system or it may be located within a totally different 
computer center. 
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2 . 3 REC'ORDING/REPRODUCING 

A. The recorder /reproducer shoul'd'be’ capable, under computer 
direction , -of selecting a'‘Speci£ic module from a ‘group of 
modules and of 'seif- loading or self- threading the selected 
module. • 

To eliminate the necessity of operator interventions, it 
,is required .that the device :be capab-le of. automatic o.pera- 
tions to record ’and retrieve data fil-es located on any ‘of 
the -"on-line" storage modud-es . 

As identified in the On-Line Mass Storage Requirements 
'Document , three of the four presently available" trillion 
bit s'torage systems are" impleme'nt'ed with ' mechanical means 
to automatically select and load their data storage mod- 
ules, Compared to human intervention, the increased access 
speed, 'efficiency, and 'cas't 'saving constftute the' major 
jus tif icati'on for these requirements. 

i . i , “ « 

B. The re'corder/rfeproducer should be mechanically reliable 
and proven by field ufeage. Time and budget constraints of 
the project do not allow a normal research and development 
period for a mechanical device to be developed and tested 
for implementation within this system. Past experience 
dictates that untested and unproven devices will cause 
serious impacts to developmen-t costs and schedules. There- 
fore, it is a requirement that only field proven mechanical 
subsystems be implemented for this task. 

It is not a requirement that the unit be originally devel- 
oped as a computer peripheral device. Some devices pre- 
sently being used in the video and broadcast industry may 
be implemented for this purpose. However, a prospective 
vendor -must provide a demonstration of a digital adaptation 
of the video device prior to final device selection. 
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2.4 USER ACCESS 

The system should accommodate multiple user access to the stored 
data and also prevent unauthorized or accidental access to, and 
modification of, secure files. The basic concept of the system 
configuration is that one or two of the host computers will supply 
most of the data stored within the data base and the other users 
will access the data for computations and analysis. 


Host computers must have the ability to do dump and roll out 
routines as well as load and roll backs, therefore, all hosts 
must have full store/recall capabilities. 

The multi-host configuration establishes the requirements for a 
Master File Directory function and full control over file activity 
and current status. 

In addition to the current methods of maintaining data security 
and integrity, it is desirable that some means of mechanical or 
physical security be devised. An example would be the present 
write lockout ring used on CCT’s. This would prevent inadvertent 
or accidental loss of master data files. 


EEPRODUCBILrrY OF TRl3 
ORIGINAL PAGE IS POOR 
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2.5 DATA RECORDS/FILES 

' A. The data should be stored in an organized manner using a 
. record size compatible with the sy-stem buffering and data 
transfer capabilities. The data system- organization, file 
size, and record size S'hall be determined as a result of 
the system trade studies concerning data flow, interface 
data rates, capabilities of the staging subsystem, and 
characteristics .of the selected recording device. - 

The physical data files should be sized such that one file,, 
or an integer multiple of files, may be s.t-ored in a module. 
The' logical record sizes will be a function of the host 
computer input/output buffer and, the channel data transfer 
rates . 

' • . I 

B. It is anticipated that future systems shall be implemented 
with the capability to retrieve data records or portions 
of files such that: total data volumes, or files need not 

be transferred into the requesting host system. 

This requirement does not stipulate that the record be 
updated in place (rewritten without damage to adjacent 
records). The requirement intent is to lessen the peak 
load demands on the input/output channels between the host 
computers and the storage system by' minimizing the amount 
of data to be transferred. 
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2.6 DATA DUPLICATION 

The system should provide a data module or file copy/duplicate and 
verify capability. For those applications where secure data files 
demand a backup copy be generated prior to, or simultaneous with a 
file access, the storage system must be capable of copying the file 
onto another module and verifying that the data copied is correct. 

This requirement specifies a system to be implemented with dual 
read/write capabilities. It is also a requirement that the stor- 
age system be capable of performing the copy/verify functions 
without the direct control of the host computer programs . 

The storage system must provide sufficient data buffering, trans- 
fer rate timing, error detection and correction, and control/ 
support software to effectively perform the copy /duplicate require- 
ments . 


2-8 



JSC-10029 


2 . 7 DEMAND/RESPONSE 

The 'system should accommodate demand/response transfer rates- 
up to 10 megabits per second. The anticipated increase in the 
.amount of imagery and telemetry .data, and the increased capabil- 
ities of satellite recorders and network communications make it 
a necessary requirement that this system be capable of handling 
data through-put rates up to 1.0 -megabits per second. 


The system should be capable of supporting these rates for file ' 
sizes which may vary from a few thousand 'bytes up to several billion 
bytes and' encompass multiple recording cartridges. 'However, during 
the peak data rate transfer, only one host system must be supported. 
Responses to other host computer requests shall be minimal until 
these high speed, near real-time demands have been met. 

Satisfaction of these requirements may necessitate the implemen- 
tation of multiple speed read/write units with speed changes 
operable under program control. The requirements will also levy 
demands upon the size and transfer rates of the data staging/ 
buffering subsystem. 



JSC-10029 


2,8 ERROR RATE 

It is' a design goal that the system error rate should be in the 
order of 10~H, corrected. It is desired that data quality 'and 
integrity be improved such that the overall system error rate does 
not exceed one error in 10^^ bits transferred. 

Several methods of error rate improvement may be implemented to 
meet this requirement. Redundant recording, polynomial encoding, 
and retransmission of data block are acceptable methods of error 
rate improvement. Methods for both random and burst error control 
should be considered, where necessary, for overall system improve- 
ment . 

System analysis and trade-off studies will determine the achiev- 
able error rates when considering data through-put rates, buffer- 
ing, and system overhead requirements. 
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2.9 DATA STAGING 

A' new technology, state-of-the-art device ’could' be considered to* 
implement the system data staging function, such as, one of the 
new high speed semiconductor memory devices in the place of the 
present disk oh. drum system as the data staging function. The data 
staging device will be capable of meeting the access^ and transfer 
rates demanded by the 10 megabit per second system through-put 
requirements . 

The more likely candidates' for this function at present are the 
beam addressed' metal-oxide' semiconductor (BEAMOS) memories under 
development at General Electric Research Center and at Microbit 
Corporation in Lexington, Connecticut. Bubble memories may also 
be considered for implementation' in this application, however, 
the -available memory capacity and system costs may make the- selec- 
tion prohibitive. > , 

It is not a requirement that this device be available in the system 
test bed configuration, but design considerations should allow for 
later implementation. 
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2.10 SELF TEST 

The system should provide a self test feature to verify functional 
operation. This requirement does not necessitate an automatic or 
in-line testing capability, however, these may be considered high- 
ly desirable features . Self testing implies that the tests be 
conducted in an off-line mode with respect to the host computer 
system. 

Where possible a test method should be implemented to determine 
the proper operation of each of the basic functions. All controls 
and displays necessary for performance validation should be in- 
cluded in the system maintenance features. 

Some feature should be included to continuously monitor and indi- 
cate the system error rate. Both the read/write errors on tape 
and the transmission errors between subsystems are candidate 
functions to monitor for an indication of system performance. 
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2.11 AVAILABILITY 

The' mass storage system shall meet the availability requirements 
of a multi-host data processing environment. This environment is 
normally characterized by 24-hour per day operation and could re- 
sult in almost continuous' u’seage o£ the mass storage system. 

To meet 'these design goals, only proven products shall be selected 
as elements' o£ the mass storage system. Where possible, o££-the- 
shel£ products with veri£iable records o£ reliability in manu- 
facture and operation shall be selected as system elements. Re- 
configuration capability shall also be used to meet the avail - 
’ability goals. Units' of storage medium shall be removable and' 
can 'be redundant. Multiple storage devices may be configurable 
for fail-over or backup operations. 

Systems ' trad'e-off studies and configuration analysis shall deter- 
mine the extent of component redundancy, ' bypass procedures, and 
allowable system degradation, necessary to meet the availability 
requirements to support a particular user application. 
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2.12 MODES OF OPERATION 

The mass storage system shall be capable of supporting basically 
two different modes of operation. The first mode, and the easiest 
to support, is that of multi-host access to the mass storage system 
in a batch processing environment. The second mode is that of a 
single host system performing high speed continuous (uninterruptable) 
data processing. System simulations and configuration analysis 
shall determine the extent of support to be provided for each of 
these modes of operations. 

In the batch mode, the processing generally can be stopped at any 
point in the process and continued with little or no loss of data, 
or processing time. This ability to stop in mid process or to 
recover from a system failure during operation exhibits less 
demands upon component redundancy and system availability require- 
ments. Also in batch mode, data processing operations can be 
tailored to meet thru-put and data rate requirements that prevent 
data losses due to over-runs, retransmission, or physical equipment 
limitations . 

The high speed continuous mode demands 100 percent system avail- 
ability during the support periods. This availability levies 
heavier requirements on the levels of component redundancy, fail- 
over procedures, and allowable system degradation. In addition, 
these support requirements directly affect equipment sizing and 
capabilities. Data transfer buffers, staging subsystem partitions, 
and storage device read/write speeds must be tailored to meet the 
thru-put and data rate requirements. 
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SECTION 3 

SYSTEM LEVEL FUNCTIONAL DESCRIPTION 


The On-line Mass Storage System shall provide a high density stor- 
age media for various user applications operating in a multi-host 
environment. As such, it shall provide all functions necessary for 
communications and data transfer between the media and the host 
system. Also included are supplemental functions that enhance 
the storage systems operations. Modularity of the mass data sys- 
tem shall be a prime consideration for implementation and design, 
in order to ensure minimum impact due to adding or deleting compo- 
nents and to permit a variety of available configurations. 

The following discussion lists those functions that should be in- 
herent in a mass storage system. There is no distinction of func- 
tions in terms of what may be implemented for a prototype configura 
tion or limited set of equipment. In addition, there is no attempt 
to classify functions in terms of mandatory, desirable, or optional 
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3.1 ON-LINE MASS STORAGE SYSTEM FUNCTIONS 

The following paragraphs indicate the candidate applications con- 
templated for the On-line Mass Storage Systems. Each application 
reflects an existing or planned need for fast access or archive 
storage. Each configuration reflects a multi-host environment, 
processing subsystem (hardware and software) , and the application 
(generally software only) . Each function requires certain opera- 
tional capabilities and characteristics of a mass data storage 
system, exclusive of the requirements levied on the design of the 
on-line mass storage system. 

System functions are outlined for the following candidate applica- 
tions ; 


• IDSD Central Computing Facility 

• Shuttle Data Reduction Center 

• Earth Resources Pattern Recognition Processing (LACIE) . 

Also included is a description of a typical application of the MSS 
to an Earth Resources Multispectral Scanner Image Processing System. 

It is not intended that a mass storage system be capable of simul- 
taneously supporting the identified functions, but that each con- 
figuration may have a storage system unique to that application. 

3.1.1 IDSD Central Computing Facility . A multi-file, fast-access 
storage capability supports the processing environment of the 
UNIVAC 1108/1110 series processor subsystem. File maintenance 
utilities of the EXEC 8 software (SECURE) are used to provide 
backup file copies, delete files, and monitor the allocation and 
use of disk storage to support this environment. For example, 
when allocated space for a data file exceeds 90 percent use, a 
potential overflow condition exists. This utility selects the 
smallest, least used file currently stored on disk for transfer to 
an auxiliary storage medium (tape) . 

In this process the mass storage medium replaces the auxiliary 
medium in both storage extent and device allocation. The mass 
storage medium provides volume storage to permit transfer of multi- 
tape files. The mass storage system must respond similar to the 
device allocated by the current operation or respond to a logical 
request for file transfer (mass storage interface handler) . 
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A second process to be supported is the transfer of files from 
mass storage to configure the host disk subsystem for the intended 
processing environment. In this case, as in the prior case, data 
is transferred from the mass storage system to the host then to 
the disk subsystem . 

A third process tOi be supported is the creation of backup files. 
Newly created files or modified files shall require the creation 
of a new backup for copy) file. This process could be supported 
by the mass storage system or obviated by its reliability. 

Utilities within the SECURE to be supported by the mass storage 
system are as follows: 

• SAVE . All SECURE files are copied to backup tapes on a 
weekly or daily basis. Weekly SAVE copies are maintained 
for 3 weeks before, daily SAVE copies are maintained for a 
week before release or deletion. Up to 60 tapes are SAVE ' d 
weekly. From 15 to 20 percent of the SECURE files are 
SAVE’d daily. 

• VERIFY . Any SAVE operation is verified and a checksum is 
performed on the block number.' 

• ROLOUT . When additional disk storage space is needed, space 
from one of the catalogued files on disk is released. If 
the tape is a newly created tape or modified tape without 

a backup, a copy is made to tape. 

• ROLBAK . If a catalogue file is requested that is available 
on the system, a request is issued for the latest backup copy 
and the file is loaded. 

• LOAD ALL . All catalogued files on disk have been cleared 
and the files must be reloaded to disk. 

Characteristics of the- functional capabilities shall include the 
following : 

A. The logical ' transaction to be performed is the transfer of 
a labeled or named file of information to/from mass storage. 
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B. The modification to the EXEC 8 software must be minimal, 
i.e., the mass storage device should be defined to the 
system as a sequential device such as a mag tape handler. 
However, mass storage system will probably require an 
additional interface handler. 

C. Transfer of a file of information shall be disk to host 
then to mass storage. File size can be a million bytes or 
greater. The mass storage system shall match the physical 
block sizes required to message process a file of data to 
the host system. Communications mode of operation, via 
the host channel, shall be a high speed, burst mode of 
operation rather than a multiplex mode of operation. 

D. Channel characteristics and channel operations of the host 
shall be emulated by the On-Line Mass Storage System inter- 
face. Operations internal for file management shall be 
transparent to the host. 

E. Multiple host systems shall be capable of creating a file, 
retrieving a file, or replacing a file. Mass sto-rage shall 
be addressable to the file level, as opposed to a contin- 
uous sequential search. Mass storage shall be manipulat- 
able to the addressable units of storage within the mass 
storage system. Addressable units of storage shall be 
mapped/allocated directly by the mass storage system or 

in multiples of the storage unit to maximize the effective 
usage of mass storage for all applications and minimize the 
file management required to map the storage throughout the 
mass storage system. 

F. Data transfer rates to the host shall be host dependent, 
up to the current design goal of 10 million bits per 
second . 

3.1.2 Shuttle Data Reduction Center . Shuttle Data Reduction 
Center functions are based on three phases of operations: 

A. Transfer of FM/PCM data from a multi-track tape source to 

an FM processor for information processing and transfer to a 
volume storage device. Once initiated, the process is con- 
tinuous until the data is exhausted from the instrumenta- 
tion tape recorder. The volume processed could be as great 
as 200x1Q6 bytes. 
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B. -Information is retrieved from volume storage by the Shuttle 
Information Extraction System (SIES) , processed, and re- 
turned to volume storage. This process is to be block- 
oriented to eliminate transfe-r of the total file to the 
system prior to initiation of processing activities. 

C. Information processed to volume storage by SIES is subj.ect- 
ed to an interactive analysis by a user in the graphics 
terminal subsystem. This process may require concurrent 
multi-file access;. 

t » • ^ 

Functional capabilities required by each operation phase are de- 
fined in the following paragraphs. 

3. 1.2.1 Shuttle Data Reduction Facility . 

• FM Telemetry Processor may require the mass storage system 
to interface to a MODCOMP IV, PDPll/45, or INTERDATA com- 
puter subsystem. 

• The application is telemetry data reduction. Processing 
could be continuous until the multi-track instrumentation 
tape is read completely. The resulting information could 
establish a file extending over more than one tape cartridge. 
File length is variable and may be composed of multiple block 

.transfers of 2000-3000 byte blocks (this is an order of size, 
not of variability in size). 

• File extent is not known when the process is initiated, 
therefore, an overflow capability is required for staging 
functions as well as mass storage allocation and use (over- 
flow to more than one cartridge) . 

3. 1.2. 2 SIES • 

• Demand/response data transfer to a large general purpose 
processor shall .be supported for block transfer sizes 
from 2000- to 10,000-bytes. 

• Channel interfaces to CYBER, PDPIO, or IBM equipments may 
be required. Simultaneous support to more than one inter- 
face may be required. 
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• Processing activities will be initiated on the data retriev- 
ed from mass storage and returned to mass storage when 
completed, i.e., 5000 bytes in, 5000 processed bytes out. 

These applications resemble standard data center processing 
activities . 

• Files may be updated/raodified in this respect: Information 

within a file can be accessed on boundaries established by 
the addressable units of storage with the storage area 
allocated to the file. The capability to update in place 
within the file of data at each addressable unit of the 
storage system shall not be required. 

3. 1.2. 3 Graphics Terminal Subsystem . 

• In this configuration, a processor subsystem with minimal 
information management software shall retrieve data from 
mass storage for user analysis. 

• Concurrent multi-file access is a distinct possibility. 

t Block sizes are of the order 1000-5000 bytes. 

• Data transfer rates to the terminal subsystem are not defined. 

3.1.3 Earth Resources Pattern Recognition Processing (LACIE ) . 

This function performs several activities that may be supportable 
by the MSS. Imagery information derived by LANDSAT shall be 
archived, manipulated, and processed. (See Figure 3-1.) The 
characteristics of the functional capabilities required to support 
these operations are as follows: 

A. Storage of several megabytes of data for periods of 3 months 
or more. Significant formatting and reformatting require- 
ments exist for the application. 

B. Storage of up to 42 ITEL 7330 disk-equivalents of data. 

C. Retrieval of 10,00’0 byte files by the Goodyear STARAN 
computer and the return of a 20, 000-byte message after 
processing. 

D. Capability to acquire data from five separate files (5 
biophases of LANDSAT data) , or an alternate capability to 
consolidate the files into a single file. 
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Figure 3-1 


Proposed Mass Storage for Earth Resources 
Processing, Functional Block Diagram 
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E. File transfer to the array processor on a demand/response 
basis. Block sizes for this transfer are not defined. 

F. Principal data to be stored includes: satellite data 

frames characterized by the frame, pixel, and scan line 
designations. User analysis requirements may reflect the 
need to select data by frame number, scan line, and pixel. 

3.1.4 Earth Resources Multispectral Scanner Image Processing 
(Typical ) . The processing functions that are performed on multi- 
spectral scanner data can typically be categorized as Preprocess- 
ing or Analysis Processing. Examples of preprocessing functions 
are reformatting, data correction such as radiometric and geomet- 
ric, and temporal registration. Analysis processing includes such 
functions as image enhancement, classification, mensuration, pat- 
tern recognition, and statistical processing. 

An On-Line Mass Storage System can be utilized to record data at 
various points throughout the preprocessing and analysis process- 
ing cycles. Example usages are input data storage, reformatted 
data storage, preprocessor output storage, analysis processor out- 
put storage, and ancillary data storage. Characteristics of these 
usages are: 

A. Input Data Storage 

• Data recorded directly from downlink if experiment data 
rate is less than 10 Mb/s. 

• For experiment data rates greater than 10 Mb/s, the data 
is first recorded at the downlink rate on a high rate 
recorder then replayed into the mass storage system. 

• Onboard recorded data is replayed into the mass storage 
system. 

• Data input to the mass storage system (MSS) will serve 
as the source data for the preprocessor. 

• Data input shall be stored in the downlink format, which 
is blocked in major and minor frames. 
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4 8 

.• Major frame size could vary from 5x10 to 2x10 bytes. 

4 

• Minor frame size could vary from 20 to 1.5x10 Bytes. 

9 11 

• Input data volume could vary from 2x10 to 2x10 bytes/ 
day for LANDSAT data or approximately 2x10^*^ Bytes/mission 
for SHUTTLE data. 

• Data must be retrieved from the MSS in addressable major 
frame blocks for reformatting purposes. 

• Input data contained in the MSS will be archived as a 
permanent record of the input experiment data. 

• Copies of input data will be provided to users upon request. 

B . Reformatted Data Storage 

• As a maximum, all input data will be retrieved, re- 
formatted, and returned to the MSS. 

• Input data will be reformatted from the downlink format 
to a band interleaved by line (BIL) or a band sequential 
(BSQ) format. 

t In a BIL format, the data -is blocked according to the 
major frame size (paragraph 3.1.4A); however, the se- 
quence of the data has been changed. 

• The BIL data can be sub-blocked by scan line, where 

' each sub-block contains the data from all bands for one 
scan line. 

• The data volume for a BIL sub -block could vary from 
l.SxlO*^ to 2.5x10^ bytes. 

• In a BSQ' format, the data is blocked by scene, where a 
scene of data represents an area equal to the swath 
width squared. 

• The data volume for a BSQ block could vary from 4.5x10' 
to 4.5x10^ Bytes. 
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• The BSQ data can be sub-blocked by band, where each 
sub-block contains the data from all scan lines in a 
scene for one band. 

• The data volume for a BSQ sub -block could vary from 
1x10^ to 4x10® bytes. 

• Data retrieved from the MSS for data correction or 
registration processing will be addressable by block 
or sub-block. 

• Reformatted data in the MSS could be archived for* 
permanent storage. 

• Copies of reformatted data could be provided to users 
upon request. 

C . Preprocessor Output Storage 

• Preprocessor output data consists of data that has been 
reformatted and corrected and/or registered. 

• All reformatted data could be retrieved, preprocessed, 
and returned to the MSS. 

• The format and block sizes of the preprocessed data 
shall be the same as for the reformatted data 
graph 3.1.4B). 

• The preprocessed data in the MSS will serve as the source 
data for the analysis processor and will be addressable 
by block or sub-block. 

• Preprocessed data in the MSS will be archived for 
permanent storage. 

• Copies of preprocessed data will be provided to users 
upon request. 
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D, Analysis Processor Output Storage 

• All preprocessed data could be processed by the analysis 
processor and returned to the MSS. 

• The format and block sizes of the analysis processor 
data shall be the same as for the reformatted data 
(paragraph 3.1.4B). 

• The analysis processor data in the MSS will be used 
as the source data for generating user products such 
as film and CCT's, and will be addressable by block or 
sub-block. 

• Analysis processor data in the MSS will be archived for 
permanent storage. 

E . Ancillary Data Storage 

• Ancillary data to be contained in the MSS will consist 
of all supporting data, exclusive of imagery data, that 
is required for annotation and image processing. 

• Ancillary data is obtained from spacecraft telemetry, 
interactive input terminals, and other support processing 
systems . 

• The volume of ancillary data is approximately 10 percent 
of the volume of imagery data. 

• Reports, tabs, catalogs, etc., generated by the pre- 
processor and analysis processor are included under 
the term of ancillary data and are stored in the MSS. 

• Ancillary data contained in the MSS may be archived 
for permanent storage. 

• Copies of ancillary data will be provided to users upon 
request . 
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3.2 FILE MANAGEMENT FUNCTIONS. 

The file management functions relate to the manipulation of data 
on a data file basis. The management file is generally organized 
into a set of physical records based on the media in which it 
resides. In addition, the user may organize the management data 
in a manner that is easy and convenient for him to utilize. This 
generally results in a unit of organization termed the logical 
record. The logical record may be smaller than, equal to, or 
greater than the physical record on a tape or a sector on a disk. 
The smallest unit of organization within the logical record shall 
be defined as the data item. Based on the above concepts and 
definitions, the following functions have been categorized as file 
management type. 

3.2.1 Data Transfer Command Interpretation .’ The data transfer 
function involves the receipt of a Logical Request from the Host 
and the interpreting of this request. The request shall include 
the folloiiring: 

• File Name or Identifier 

• Source of File 

• Destination of File 

• User Code or Identifier 

• New or Old File 

• Other Housekeeping Information. 

3.2.2 Master File Directory . The MSS shall be responsible for 
the maintenance of a Master File Directory. The directory shall 
contain: the list of all data sets currently resident in the sys- 
tem, their location in the system, an indication of their status 
(active or archived), date of creation or most recent update, and 
any other necessary identifying parameters. 
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3.2.3 Data Transfer Function . The initiation and monitoring of 
all data transfers between devices of the mass storage facility 
shall be the responsibility of the System Control Unit (SCU) . 

The data transfers shall be accomplished on a complete file basis. 
Any necessary blocking and unblocking Cfo^’inatting) of physical 
data records between device types shall be performed. Advisories 
of transfer completion and status shall be referred to the' host 
system. The status shall indicate any error or abnormal condition 
encountered. Retry- attempt s , where warranted, shall be initiated 
to complete -an unsuccessful data transfer. If a requested file 
is not , on line (designated as -archived in the Master File Directory), 
an operator advisory shall be issued. The host system shall also 
be advised of the status. 

3.2.4 Security Function . The validation of user codes against 
access authorization codes shall be performed in order to ensure 
proper dissemination and modification of data. 

3.2.5 Host Communication . The On-Line Mass Storage System shall 
perform all the necessary basic communication functions with the 
multi-host system. 

3.2.6 Peripheral Devices Handlers . All special and standard 

peripheral devices connected to the MSS control bus shall be 
initialized, controlled, and statused by the respective I/O 
handlers. The I/O handlers include: the high density recorder 

controllers, staging controller, and host channel interfaces. 

3.2.7 Transaction Logging . All transactions related to a Host 

request shall be logged for subsequent analysis and recovery 
efforts. Logged data shall include: user ID, file name, transfer 

types, transfer status, and other pertinent activity and per- 
formance data. 

3.2.8 Volume Directory . The system shall record a directory for 
each storage module that identifies its contents. The directory 
shall contain a module ID and a file directory. The file directory 
shall identify each file name or identifier contained in the module, 
its starting location, access codes, and date of creation or last 
update. 
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3.2.9 Module Handling .> The MSS shall provide the capability to 
remove and mount storage modules within its system. This shall 
include the proper update o£ the Master Data Directory to indicate 
files removed due to the unloading of a cartridge. It shall also 
indicate new data sets available for access when a new cartridge 
is mounted. 

3.2.10 Archival . The intent is to provide a tool by which data 
modules may be identified removed and labeled for transfer to 
archive status. An Archival Directory shall be maintained listing 
all archived data. The archive -directory shall include the same 

'type information as the master directory. 
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3.3 RESOURCE MANAGEMENT FUNCTIONS 

In order to ensure effective utilization of components and resources 
available, and to monitor activity, the system shall perform func- 
tions designated as Resource Management. These functions are iden- 
tified in the following paragraphs. 

3.3.1 Component Activation . Since the MSS is composed of in- 
dividual devices and modules, the control of da-ta paths and/or 
items that are active shall be provided by the SCU. Priority of 
transfers shall be established to resolve contention for paths or 
components . 

3.3.2 Device Utilization . The system utilization of the Storage 
and Staging Subsystems shall be performed by the SCU. A current 
mapping of the individual units utilized shall be monitored to 
assist in identifying the amount of reserve available, and full 
or saturated units. Proper advisory to the cognizant personnel 
shall be provided. 

3.3.3 Analysis Reports . The generation of statistics or reports 
on the system transactions shall be accomplished for use in opti- 
mizing performance, identifying usage, monitoring system reliability 
and capacity, and recognizing changes required in the system. The 
reports and information may be provided on demand or periodically 

in hardcopy form. 

3.3.4 File Management Backup . In order to ensure availability to 
critical Host environments, the system shall provide a backup cap- 
ability where requirements so dictate. 

3.3.5 Acknowledge Completion of Job Tasks . The system shall 
provide responses to the host computer indicating the successful 
or unsuccessful completion of operations requested. For un- 
successful operations, status information shall be sent to the host 
computer indicating the cause of the failure of operation. 

3.3.6 Redundant Recording . If required, to meet the objective 
system error rates, the system shall allocate data recording in 
such a manner that the data will be recorded redundantly on the 
media to ensure that data will not be lost due to storage irreg- 
ularities. Bad areas, on the media, if previously marked, shall be 
detected and avoided during normal read/write operations. 
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3.3.7 Automatic Switchover . Ths system shall provide automatic 
switchover to a redundant subsystem, i£ a failure occurs during 
operation. The extent of redundency shall be determined as a 
result of the trade-off studies and configuration analysis. 

3.3.8 Quality Control . The system shall perform a quality control 
function on data sets through system validation routines to ensure 
data integrity and maintain statistics of good/bad data records. 

The system shall also implement an error detection and correction 
encoding scheme capable of maintaining required system error rates. 
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3.4 UTILITY FUNCTIONS 

The £ollowi.ng utility functions are necessary to supplement the main 
functions. In general these functions are operator, not host, 
initiated. 

3.4.1 Media Initialization . If the subsystems are required to 
be initialized prior to placement on-line, this function shall be 
performed by the SCU. The initialization function may involve 
writing track addresses, status ing and marking bad tape or memory 
areas, writing starting data positions of tracks or sectors, load- 
ing file directories, allocating staging boundaries, etc. 

3.4.2 Copy Function . The MSS shall provide the capability to 
copy a current file from one cartridge to another cartridge. 

3.4.3 Dump Capability . The system shall provide a formatted 
Dump of the Master File Directory or Volume Directory in hardcopy 
form. Also a formatted binary dump of a file by Track, Block, 
etc., shall be available. As an option, a display may be utilized 
if a CRT device is available. 

3.4.4 Purge/Delete Capability . A utility function shall provide 
the ability to purge an entire volume or to delete a specified file 
including its directory information. Special files, designated 

as temporary by the user, shall be deleted based on a predetermined 
usage algorithm. 

3.4.5 Tape Organization . The purpose of this utility function is 
to reorganize a tape to enhance its usage. Deleted and purged 
files shall be removed and all remaining active files packed 
together to better utilize tape space. 

3.4.6 System Recovery . The system shall have the capability of 
performing system recovery of any outstanding transactions due to 
a system failure. 
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3.5 DIAGNOSTIC FUNCTIONS 

The diagnostic functions shall assist in the troubleshooting and 
diagnosis of the data storage unit controller or the staging unit. 
System functions are assumed to be available for the mini-computer 
and its peripherals as standard deliverables from the manufacturer 
and are not discussed here, 

3.5.1 Subsystem Diagnostics . This function shall provide the 
operator with the capability to select and initiate those functions 
necessary to verify operation of designated controllers or periph- 
eral devices. The monitoring of the specified action and its status 
shall be returned to the maintenance personnel as required. 

3.5.2 Media Diagnostic . Media diagnostic functions relate to the 
storage media itself (the tape cartridge) . This set of diagnostics 
shall include the capability to identify bad tracks, blocks, etc., 
and to provide the proper marking on the media. 
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SECTION 4 

FUNCTIONAL CONFIGURATION 


4.1 INTRODUCTION 

The On-Line Mass Storage System is separable into four subsystems; 
(1) Host Interface Units, (2) System Control Unit, (3) Mass Data 
Storage Equipment, and (4) Staging Subsystem. Interaction between 
‘these subsystems and the communications paths necessary to perform 
these functions are illustrated in Figure 4-1. 


A. Host Interface Units . Host computer systems shall access 
the mass storage system through the individual Host Inter- 
face Unit (HIU) . These units shall provide the handshaking, 
command interpretation, interrupt acknowledgement and re- 
sponse, data reformatting, timing, and buffering necessary 
to interface the host systems to the System Control Unit 
(SCU) and the Staging Subsystem controller. 


B. System Control Unit . The SCU shall monitor and control all 
activities concerned with the storage and retrieval of data 
files within the On-Line Mass Storage System. The SCU shall 
configure and control the activities of the HIU, the Mass 
Data Storage Equipment (MDSE), and the Staging Subsystem. 
Logical requests from a host system shall be validated and 
processed by the SCU. All file management functions shall 
be performed by the SCU including: management of the 

Master File Directory, storage allocation, and command 
processing. The SCU shall issue a physical request to the 
MDSE to access a specific area of the medium for retrieval 
or storage of data. The SCU shall configure and control 
the elements of the On-Line Mass Storage System for the 
transfer of data to/from the host system. Quality assur- 
ance functions shall be performed by the SCU to ensure the 
complete transfer of a file of informati.on. 
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Figure 4-1. Mass Data Storage System, Functional Diagram 
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C. Mass Data Storage Equipment . MDSE shall provide the volume 

storage capability for the Mass Storage System CMSS) . Each 
storage unit shall consist of: a volume tape storage me- 

dium; two separate and independent read/write stations; and 
all associated electronics for addressed search, writing, 

.and' recovery of recorded data. Each storage unit shall 
' pro.vide multiple removable cartridges as the storage medium. 
Each of the cartridges shall be selectable by computer 
control,, retrieved, mounted, and threaded automatically at 
the selected read/write station. Each read/write station 
shall interface the SCU to receive the access request for 
file management functions. Each read/write station must 
also interface the Staging Subsystem to transfer data. 

An error detection and correction capability shall be pro- 
vided by each read/write station to the data transferred to/ 
from a cartridge. Error correcting techniques applied to 
the retrieved data shall be independent of the read/write 
S'tation used to record the data. 

D. Staging Subsystem . The Staging Subsystem is a multi-ported 
volume storage equipment operating as a passive device to 
provide the storage for concurrent read/write operations 

by the MDSE and HIU. The staging equipment shall support 
the read/write rates established by the source/destination 
devices of the host systems and the MDSE. 

Support of a multi-host environment may require partitioning 
the volume storage of the Staging Subsystem. Partitions in 
the passive device may either be predefined based on assign- 
ment of physical interfaces (HIU’s and Read/Write Stations), 
or created dynamically by the SCU. In the latter case, the 
partitions would' be created by the SCU in its management of 
the volume storage of the Staging Subsystem. Partitions of 
the Staging Subsystem would also be assigned by the SCU in its 
configuration and control of file transfers through the 
subsystem. 
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4.2 HOST INTERFACE UNITS 

The HIU functions are illustrated in Figure 4-2. Each HIU connects 
the communications channel of the host system with subsystems of 
the MSS. Logical requests, i.e., host requests for file retrieval 
or creations, are transferred from the host to the SCU via the HIU. 
Physical data transfers to/from the host system are routed from/to 
the Staging Subsystem via the HIU. In addition to. its communica- 
tions responsibility, the HIU shall isolate each system from the 
other. A HIU shall also isolate a failure of the MSS from the host 
system and vice versa. In effect, all activities performed by the 
MSS shall be transparent with respect to the requested operation. 

A HIU must match the original equipment manufacturer interface 
specifications. These specifications describe the sequence of 
channel commands, diagnostics, and error condition to be emulated 
by the Mass Storage System Interface Unit. For each host system 
supported, one or more HIU's may be required. Types of systems 
to be supported include: the UNIVAC 1100 series computer sub- 

systems (1108/1110), CDC CYBER series computer systems, IBM 360/370 
selector channels, and minicomputer interfaces such as the INTER- 
DATA 8/32. HIU design shall be compatible with support of any of 
the above interfaces. However, a single host interface type shall 
be selected for development as the prototype unit for the test bed 
configuration of the MSS. 

Isolation of the systems shall be accomplished through control of 
the logical (formats, types of commands, conventions) and physical 
(hardware interface, timing) components of the HIU. To support 
interface control, the interface unit may be required to reformat 
or align the data transferred from one system to the other. In 
addition, the interface unit shall have the capability to support 
on-line and off-line modes of operation, with respect to the host 
system, without inhibiting host activities to other equipment 
sharing the same host channel. 
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Figure 4-2. Proposed SDRC Configuration Host Interface 
Unit, Functional Diagram 
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4.3 SYSTEM CONTROL UNIT 

Control of the configuration and communications within the Mass 
Storage System shall be accomplished by the SCU. The SCU shall 
also perform' all file management functions for the system. The 
SCU functions are illustrated in Figure 4-3. Cost and design 
goals of the Mass Storage System, support the application of a 
minicomputer architecture to the SCU functions. 

4.3.1 SCU Control Function . The SCU shall configure and control 
the MSS equipment via interfaces to each HIU, MDSE recorder unit, 
and Staging Subsystem. In addition, the SCU shall support the 
peripheral complement of the minicomputer system; disk, tape, 
operator station, card reader/punch , and printer. At least 16 
I/O interfaces shall be supported by the SCU. The SCU shall 
establish the on-line, off-line, test, and maintenance modes of 
operation for the MSS equipment via these interfaces. 

4.3.2 SCU Communication Function . Communications control by the 
SCU includes the management of host requests and MSS responses 

in a multi-host environment. At least four host interfaces shall 
be capable of concurrent operations in the MSS. At least two 
MDSE units, each complemented by two read/write stations, shall 
be capable of providing the on-line mass storage. The Staging 
Subsystem shall consist of single or multiple storage elements 
to be allocated by the SCU to a HIU or to a specific file transfer 

The SCU shall queue the logical requests from host systems. Each 
host request shall represent a "transaction” to the system. Trans 
actions shall then be assigned a priority by the SCU, however the 
transactions may be processed partly in parallel due to the wait- 
times for access to the MDSE. The SCU shall then assign a com- 
munications data path for the transfer, to include: the selection 

of a read/write station, partitioning or configuring the staging 
subsystem, designation of the HIU, and coordination of the read/ 
write operations on the staging subsystem in order to support 
continuous stream processing. The SCU shall also provide the 
capability to trace a transaction through the processing steps in 
order to ensure valid and complete file transfer. 
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System Control Unit Functional Diagram 
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4.3.3 SCU File Managment Function . All file management functions 
are performed by the SCU. The SCU shall validate and process all 
host requests, such as; 

• Retrieve filename 

• Insert or catalog filename 

• Purge filename. 

The SCU shall manage the directory of all files of information 
defined to the system and maintain a current catalog of all files 
on-line in the Master File Directory. 

The SCU shall manage mass storage resources including allocation 
and deallocation of MDSE storage capability. The unit of storage 
allocated shall be selectable as an installation parameter and 
shall be defined in the detailed design phase. The directory of 
file names shall include the FILENAME, physical address of the 
stored information, and file length in terms of the number of 
storage blocks allocated. 
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4.4 MASS DATA STORAGE EQUIPMENT 

The MDSE functions are shown in Figure 4-4. The MDSE shall be 
comprised of magnetic tape drives and controllers to interface 
with the SCU and Staging Subsystem. Controller interfaces shall 
be designed to minimize the software required for the recording, 
searching, and playback of non-sequential data files from tape. 

This equipment shall be cumulative to provide a volume storage 
capability of 50 x 10^ bytes (8 bits/byte) with access times for 
a file of information in a storage unit less than 30 seconds. 

Provision shall be made to enable selective ‘addressing of specific 
data records, on tape, for the purposes of writing, reading, or 
modifying operations. Data record addresses shall be capable of 
being read during high speed search operation in either forward 
or reverse direction. The controller shall automatically perform 
all required tape search operations and place the data into buffer 
storage (read operation) , or retrieve the data from buffer storage 
(write operation) without SCU intervention. When completing the 
requested task, the controller shall interrupt the SCU with noti- 
fication that the requested command has been either completed or 
unsuccessfully attempted. 

The MDSE shall provide the capability to detect and correct the 
characteristic errors of the recording medium to provide an error 
rate of a single bi.t in lOH bits of data transferred. Techniques 
used to accomplish the error rate shall be independent of the read/ 
write station and device/cartridge combination used to record the 
data . 

Dual read/write capability is a minimum requirement for a recording 
unit of the MDSE in order to support the multi-host environment 
of the MSS. Dual read/write capability shall also support the 
copy and verify functions of the system to create and verify a 
copy of an existing file. This capability shall also be used to 
support the "wrap-around” condition encountered in "continuous in 
input processing", i.e., as a cartridge is filled another cartridge 
is readied to begin recording. 

A recorder unit shall have a selectable or servo-driven variable 
rate capability. Variable record rates shall provide the capabil- 
ity to support a wide class of host applications and minimize the 
volume storage requirements on the Staging Subsystem. 
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Figure 4-4. Mass Data Storage Equipment, Functional Diagram 
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Cartridges used in the MDSE shall be removable and interchangeable 
between units. The magnetic tape shall be contained in a dust- 
tight protective cartridge and self-threaded by the tape drive, 
thereby eliminating the possibility of operator induced tape con- 
tamination, edge damage, or other problems normally occurring with 
human handling and shelf storage of tape. The storage modules 
shall be self-contained and evidence no degradation of performance 
when stored for a period of 3 to 5 years in a normal computer room 
environment. Degradation of performance is interpreted as exces- 
sive error rates when the data is retrieved after being stored in 
a normal computer room environment. The capability shall exist to 
interchange tape recordings for update or playback on MDSE of the 
same type, i.e., recordings made on any MDSE can be used on any 
similar MDSE. This playback requirement shall meet the specified 
operating performance on any of the MDSE units . 

The commands for the MDSE shall be interlocked so that tape or 
equipment damage is impossible, as the result of any combination 
or sequence of commands. An illegal combination of motion commands 
shall result in the tape recorder entering the STOP mode'. Status 
information with regard to the operating mode, tape position, and 
command in process shall be accessible by the SCU at all times. 

In addition, the MDSE shall contain a maintenance panel for computer 
control simulations, and off-line testing and maintenance functions. 
All Motion and Function commands to the MDSE shall be SCU control- 
lable and switch selectable to local control for maintenance 
purposes. ‘ 

Each circuit or groups' of circuits shall be designed such that a 
catastrophic component failure shall not cause damage to associated 
components or' circuitry. The design shall also eliminate the need 
to sequentially turn ON or OFF power supplies, etc. Random loss 
or submarginal performance of any power supply(s) shall not cause 
damage to the circuits or components . 
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4.5 STAGING SUBSYSTEM 

The staging subsystem functions are illustrated in Figure 4-5. 

The staging subsystem is an extension of mass storage capability 
to enable the transfer of information from the high density volume 
storage device to the demand/response interface of a host proces- 
sing system. The staging device shall support the interface rate(s) 
of the mass storage recording device for data transfer to/from 
mass storage. The staging device shall also support the demand/ 
response characteristics through the HIU supporting rates up to 
10 million bits per second. The staging device for the MSS shall 
be configured by the SCU to support data transfers from a host to 
mass storage and from mass storage to a host. 

Host applications (Refer to Section 3) to be supported could re- 
quire the staging subsystem equipment configuration to take the 
form of a number of storage elements (partitions or volume storage 
elements) each with a read or write capability. The Staging Sub- 
system could also be constructed as a single volume storage element 
with multiple ports to permit concurrent read and write operations. 
Volume storage capability of the Staging Subsystem shall be of the 
order of several megabytes of data, Size of the volume storage 
depends directly on the methods used to partition the storage 
capability for use in a multi-host support environment. The re- 
lationship between volume requirements and the partitioned support 
of a multi-host environment shall be derived in the detailed design 
phase of the system. 

Size of the staging subsystem stbrage or the "apparent” size of 
Its .storage is also important to operations of the recording de- 
vice. Inability to support a continuous transfer of data to/from 
the recorder will require the device to stop, reposition, and re- 
start at the resumption of data transfer. Several alternatives 
exist to minimize the stop/start activities of the device includ- 
ing the design of a device to match or synchronize the rate of the 
recorder with the "apparent" or available storage of the staging 
device . 
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Conceptual design of the Staging System proposes a "passive" 
volume storage element as the device. This device shall support 
DMA type operations by the MDSE or HIU in the following manner. 

A logical request to the SCU would result in pre-determination of 
the partitions required in the staging system to support the re- 
quest. Up to 100 percent of the Staging Subsystem could be assigned. 
Partition characteristics would be then provided to the HIU and 
MDSE, and their interfaces monitored to initiate the sequence of 
read/write operations performed. The rate-matching function noted 
above may be required to eliminate any potential overlap of concur- 
rent read/write operations. The Staging Subsystem shall complement 
the error protection incorporated by the 'HIU or MDSE to protect 
data transfers, e.g., parity checks on a word boundary could be 
supported by the Staging Subsystem. 


4-14 



JSC-10029 


SECTION 5 

MASS DATA STORAGE SYSTEM OPERATIONS 
5.1 introduction' 

This section provides, in sequential descriptive format,, the 
possible or probable operations necessary within the mass storage 
system to perform the basic tasks identified in Section 3- The 
task descriptions are intended to be general in nature such that 
a system design can be accomplished without limiting the applica- 
tions or usefullness of the system to performing only these 
identified operations . 

It is assumed that most or all of the system applications can be 
supported by the proper utilization of one or more of the follow- 
ing operations: 

• Recall/Retrieve Data Files 

• Store Data Files 

• Retrieve/Modify/Replace Data Files 

• Load Files (Cartridges) 

• Remove/Archive/Exchange (Cartridges) 

• Copy Files (Off-line) 
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5.2 RECALL/ RETRIEVE DATA FILES 

The following operation description is based on the assumptions that 
both the host system (or multi-hosts) and the MSS are functioning 
properly, the Master File Directory (MFD) and all support programs 
have been loaded, the subsystems and interfaces have been checked, 
and the host application has initiated a logical request to re- 
trieve a data file. 

A. Host channel program or I/O control program initiates a 
service request to the Host Interface Unit (HIU) according 
to the vendor' channel interface specifications. 

B. If the HIU is not busy, i.e., control of the interface has 
been released from the last transaction, the HIU must re- 
spbnd to the request for service. 

C. The HIU then transfers the logical request, "RECALL FILE- 
NAME" or "RETRIEVE FILENAME", to the System Control Unit 
(SCU) to retrieve and transfer an information file to the 
host system. 

D. The logical request is examined by the SCU for validity, 
i.e., format and filename are examined for uniqueness with- 
in the facility. 

E. When the SCU verifies that the request is valid (file is 
accessable by the requesting host), the MFD is examined 
for physical address of its location. This physical 
address specifies the device number, cartridge number, 
cartridge location, and file address that must be identi- 
fied to the system in order to complete the request. 

F. If the required cartridge is not currently assigned to the 
system, an appropriate response to the system operator 
must be made. If the file is "on the system", an access 
request will be formatted and queued to the MDSE. 

G. The MDSE controller then responds to the access request 
and commands the selected cartridge to be positioned on 
an un-busy read/write station. If both stations are busy, 
the command is placed in queue until a station is available. 
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H. With the cartridge in place and the files being searched, 
and as the read/write head is approaching the requested 
address, communications are enabled to the staging device 
for the requested tape-to-host file transfer. 

I. This communication is established by an MDSE request to 
the SCU for a data path to staging. 

J. The SCU interrupts the Staging Subsystem controller, re- 
questing a file transfer giving source. device/s tation and 
destination (HIU address) along with the starting and end- 
ing addresses of staging to be allocated. 

K. As each physical block or track of information is transferr 
ed, the data quality is checked and an error correction 
routine is initiated, when necessary, to obtain the pre- 
determined error rates. 

L. As the physical blocks or tracks of information are trans- 
ferred, the staging device accumulates the volume specified 
Double buffering of the staging volume is anticipated to 
allow simultaneous filling and emptying of the staging area 

M. A buffer full flag from staging initiates an SCU request 
to the host interface for transfer of the file to the host 
system (Input Data Request). 

N. When the SCU receives an input acknowledge from the host 
channel, the data path is established between the staging 
subsystem and the host channel interface unit. 

O. The volume of data in staging is transferred to the host 
under the control of the input channel. The host interface 
shall check the data quality as the data is transferred. 

NOTE 

The size of the data blocks transferred from the 
staging device depends upon the application and 
addressable storage units of the staging subsystem. 

The data path from host to staging operates in a 
demand/respond mode and may be double buffered to 
provide adequate timing and interface with the re- 
ceiving device. 
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P. When the transfer is complete, SCU is notified and the path 
IS initialized for transfer of the next volume. 

Q. Once transfer of the file is complete, a summary message 
must be derived by the SCU from MDSE and Staging. This 
summary message shall also be provided to the operator 
station and the host system. The SCU then releases the 
staging area for other usage and records the transaction 
in the activity log. 
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5.3 STORE DATA FILES 

As in the procedure for retrieving a data file, it is assumed 
that the host system (s) and the mass storage system are function- 
ing properly, that the Master File Directory and support programs 
have been loaded, the subsystems and interfaces have been checked, 
and that the host application program has initiated a logical re- 
quest to store a data file. 

A. Host channel program or I/O control program initiates a 
service request to the HIU according to the channel inter- 
face specifications. 

B. If the HIU is not busy, i.e., control of the interface has 
been released from the last transaction, the HIU must re- 
spond to the request for service. 

C. The HIU transfers the logical request "STORE FILENAME" to 
the SCU to allocate an area on the storage device and re- 
ceive the information file which is awaiting transfer. 

The request states the source code, file size (number of 
vvords or blocks), and the type of data (new file, old file 
or update) . 

D. The logical request is examined by the SCU for validity, 
i.e., format and filename are examined for uniqueness 
within the file directory. 

E. The SCU then searches the MFD for the physical location 
of the requesting hosts OLD files. It is determined 
whether the cartridge containing the old files is presently 
"on the system" and if there is sufficient area remaining 
on the cartridge to contain the information file. 

F. If the required cartridge is not on-line or a new tape is 
necessary to contain the file, the SCU makes the appropriate 
response to the operator. 

G. The SCU formats and queues a storage request to the MDSE. 

The MDSE controller responds and commands the selected 
cartridge to be loaded on an un-busy read/write station. 
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H. Responding to a "search and halt" command, the tape is 
positioned at a predetermined track address and the read/ 
write station is ready to accept data. A ready message is 
sent to SCU which notifies the HIU to initiate transfer of 
the file, 

I. SCU then commands the staging controller to accept data 
from HIU and provide the required buffer area. The SCU 
also provides the staging area mapping functions along 
with the starting address and word count. 

J. When the data bus and staging area are available, the file 
is transferred on a demand/response basis under the control 
of the HIU. 

NOTE 

The staging area is considered to be double buff- 
ered for timing and data throughput rate matching. 

It is highly desirable that the tape drives pro- 
vide variable speeds such that the throughput rates 
from host to tape can be compatible and the nec- 
essary staging area can be minimized. 

K. As the first staging buffer is filled, the buffer full flag 
to SCU initiates the staging to MDSE data transfer. 

L. The tape is brought up to speed and the file header is 
written as the data is assembled into the track assembly 
registers . 

M. Data is continuously transferred from alternate staging 
buffers to the MDSE until the file transfer is complete. 

N. When the block count is reached or end-of-file is detected, 
the HIU notifies the SCU. 

O. As the last of the file is transferred to tape, the SCU 
will status the MDSE for errors, overruns, lost data 
blocks, etc. If the transfer is successful, the path is 
cleared and the staging buffer area is released (no retry 
is necessary). The SCU also sends a message to MDSE to 
rewind and store the cartridge, and set the read/write 
station to a not-busy state. 
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P. SCU also updates the MFD and records the transaction in the 
activity logs. 
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5.4 RE'TRIEVE/MODIFY/REPLACE DATA FILES 

Thxs section describes the procedures necessary to simultaneously: 
retrieve an extensive file of data from tape, allow the host appli- 
cation to modify the information in small portions, and store the 
modified data in a new file located on a different cartridge. The 
systems are assumed to be functioning properly and that the host has 
requested an access to "RETRIEVE FILENAME". Also, the systems 
shall have performed validation, MFD search, and data retrieval 
functions as described in paragraphs 5.2 A through P. 

A. If the logical request to "RETRIEVE FILENAME" has been 
processed properly and a correct response received by the 
host, the host shall initiate a second logical request to 
MSS through a separate I/O channel and Host Interface Unit 
prior to any data transfer. 

B. This second request, to "CREATE FILENAME", requests initial- 
ization of a file in the file directory and allocation of 
storage for the. new file. 

C. The logical request is examined by the SCU for validity, 
format, and uniqueness of the file name. The file name 
may represent a new file or a current copy of an old file, 
however, the file indication must be unique. 

D. If the file name is unique, storage area must be allocated 
for the pending transfer. 

NOTE 

Prior to the job initialization, the operators 
instructions shall have described procedures 
for providing clean certified cartridges for 
new file allocation. Also if the input file 
is contained on more than one cartridge, all 
cartridges shall have been loaded on the MDSE 
in locations to minimize the delay necessary 
to put away one cartridge and replace it with 
another. 
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E. The SCU formats and queues a physical request to the MDSE 
controller to position a new cartridge on the second read/ 
write station, validate the cartridge number, record the 
file header, and standby for the new file data to be stored. 

F. With the storage device ready to accept data, a message is 
sent to SCU which notifies the HIU and the host system that 
both the input files and the output files have been set up. 

NOTE 

Since it is the purpose of the task to input an 
extensive file, modify it in small pieces and 
output it ”on the fly'*, the system configuration 
requires a dedicated data path for both the input 
and output files. The task utilizes both read/ . 
write stations of the MSDE and two separate HIU's. 

No other tasks shall be supported until the com- 
pletion of this task and the units can be re- ' 
leased for other assignments. 

G. The data input process shall proceed as described in para- 
graph 5.2 "RETRIEVE FILENAME" and the output process as 
described in "STORE FILENAME" in paragraphs 5.3 I through 

P. 

NOTE 

This operation levies the requirement upon the 
staging system and the SCU that the staging 
ar,ea is partit ionable , capable of full duplex 
input and output and that some means of 'memory 
protect » be implemented to prohibit accidental 
overrun or other destruction of file data. 

H. To complete the RETRIEVE/MODIFY/REPLACE procedures, the 
SCU must accumulate the status messages and compare the 
number of data blocks transferred, staged and stored. If 
all transfers are verified and no blocks are lost, a success 
ful transfer is reported to the host. 
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5.5 LOAD FILES (CARTRIDGES) 

Provisions should be made for manually loading the cartridge hand- 
ling equipment (carrousel) and the creation of a listing of the 
"working files" within the file directory, as opposed to the ar- 
chived or off-line files. 

Operational procedures shall specify (from task descriptions or 
job orders) which files are to be brought from the library and 
loaded on the MDSE for those tasks. 

A. The operator shall manually load the carrousel with the 
requested tape cartridges, then enter a request from the 
console that an initial loading form be displayed (on a 
CRT) to enable the input of data to the "working file" 
directory stating cartridge locations. 

B. When the form is completed and entered, the SCU builds 
the ON-LINE file directory by searching the MFD until 
the files associated with the cartridge number have been 
located . 

C. These FILENAMES are then listed or tabulated in an area 
designated as the working file index. The list identifies 
all labled files as being "on-line". The listing is com- 
pleted for each of the cartridge numbers entered. 

NOTE 

To eliminate the possibility, of a mistake or 
an input error when loading, each cartridge 
number will be verified when the cartridge is 
selected and positioned on the read/write 
station. This can be accomplished by placing 
the cartridge number in the search track at 
the beginning of tape such that the first 
information received is. that number and it 
can be compared immediately with the request 
from the SCU before the first addresses have 
been reached. 


5-10 



JSC-10029 


D. During the normal data base activities when a file is re- 
quested and is not listed in the working file as being 
on-line, SCU searches th.e MFD to determine the correspond- 
ing cartridge number. 

E. The SCU then notifies the operator to retrieve the cartridge 
from library. The operator must decide which position can 
be unloaded and the new cartridge inserted. The operators 

' of the host computer systems may be polled to aid in the 
selection of files to be removed. Operational guidelines 
will be established for this purpose. 
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5.6 REMOVE/ARCHI EVE /EXCHANGE FILES (CARTRIDGES) 

Provisions must be made for methods to determine whether a cartridge 
position is filled or unloaded. The method should be mechanical 
and provide a position status indication to the MDSE controller. 

5.6.1 Initial Cartridge Requests 

A. As a cartridge is removed from a location, the status 
changes from loaded to unloaded. The change should cause 
an interrupt to the SCU requesting an update to the work- 
ing file directory, giving the corresponding position. 

B. The SCU then scans the position/cartridge number table 
and sends the cartridge number to the working file identi- 
fying those files that are being deleted. 

C- The "on-line" file catalog is purged of the corresponding 
FILENAMES. No further action is necessary to identify the 
files as being returned to archive status. The fact that 
they are no longer listed in the on-line index is suffi- 
cient indication. 

5.6.2 Subsequent Cartridge Requests . Subsequent requests for 
those files or a request for other files from the lib"rary \vill be 
handled in the following manner; 

A. As the new cartridge is placed in the empty position, the 
status indicator changes to "filled". 

B. The status change causes an interrupt to the SCU for a re- 
quest that the loading form be displayed on the CRT. 

C. The loading form is then updated with the new cartridge 
number for that position. 

D. As the update is entered, SCU searches the MFD for the 
associated FILENAMES corresponding to the cartridge number. 

E. The working file directory is updated with a listing of 
those new FILENAMES. 

F. The cartridge number will be verified, as previously stated, 
upon the first access for information from that particular 
cartridge . 
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,-5.7 COPY FILES (OFF-LINE^ 

The following procedures are required to copy or duplicate a file, 
i.e., read the information on an existing cartridge and copy it 
onto another cartridge. It is also required that the COPY function 
be performed "off-line" from the requesting host system, primarily 
within the MSS. 

In addition to the host system providing the initiation of a copy 
request , other sources which can initiate a copy/duplicate request 
are; operator initiated requests from the SCU console and from 
software initiated requests resulting from a subsystem monitor 
within the SCU. File monitors state that when a particular file 
has been read (or accessed) a fixed number of times or the read 
error rate has reached a minimum threshold level, a new file 
shall be created from the "OLD" file data. 

The assumptions for copy files are the same as in the previous 
paragraphs concerning the proper functioning of the subsystems and 
the loading of the file directory and support programs. 

It is also assumed that the MDSE Controller will have sufficient 
data buffering to allow data to be transferred from one R/W station 
to the other without requiring the utilization of the Staging 
Subsystem. 

5.7.1 Host "COPY FILENAME" Requests . 

A. The host channel program or I/O program initiates a service 
request to the HIU . If the interface is not busy, it must 
respond to the request for service. 

B. The host transfers the logical request "COPY FILENAME", to 
the SCU to duplicate the contents of one file to another 
area on a different cartridge. 

C. The logical request is examined by the SCU for validity and 
the MFD is examined for the physical address of its location. 
If the file is "on the system", an advisory is sent to the 
MSS operator that a copy request has been made. 
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D. Operator mounts a clean, certified tape cartridge, calls up 
the initial loading form, and keys in the new cartridge 
number and location to the File Directory. The input should 
specify that this is a new tape. 

E. The SCU formats and queues a storage request to the MDSE. 

The MDSE controller responds and commands the new cartridge 
to be positioned on read/write station number two. 

F. When the cartridge is in place and the read/write station 
is ready to accept data, a ready message is sent to MDSE 

to "COPY*' the file from the location being provided, to the 
newly allocated storage tape. 

NOTE 

The COPY command is interpreted by the MDSE 
controller to position the requested cartridge 
on read/write station number one and to enable 
a data path between the read/write stations 
for direct transfer of the data from the out- 
put of number 1 to the input of number 2. 

In addition, the SCU COPY command sets up and initiates the 
data verify circuitry necessary to determine the quality of 
the data being transferred. This circuitry shall decode 
the block or track numbers and temporarily hold the number 
in a register until the block has been received at station 
number 2. If an error is detected during transfer a re- 
sponse is sent to the SCU notifying it of an error and 
giving the block or track number in which it occurred.. 

G. The file is transferred on a continuous basis under the 
control of the MDSE controller, with timing and speed 
control for station number 2 being provided by station 
number 1*. 

H. When the transfer is complete, i.e., end-of-file detected 
or block count complete, the SCU is notified. If no errors 
were detected, or the error rate is under the specified 
number indicating a valid copy, the file directory is up- 
dated with the new FILENAME and physical location information. 
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I. The SCU then sends a ’’copy complete” message to the host 
system via the HIU. The host will respond with directions 
to the operator as to the retention or distribution of the 
master and copy files. 

5.7.2 Operator Initiated "COPY FILENAME” Requests . In this mode 
of operation, the request for copies may be initiated from the 
operators console [CRT keyboard) . The requests may be the result 
of a stand-alone job order requesting copies to be made of certain 
files [imagery, telemetry, etc.) to be shipped to another location 
and implemented within a remote system. 

The requests may also result from job orders that require copies 
to be generated for security or protection from system catastrophic 
failures. Requests for copies should be generated during periods 
of low activity since the process requires the utilization of both 
read/write stations, and access to the MDSE is prohibited until the 
copy routines are completed. 

A. The logical request "COPY FILENAME” to the SCU is initiated 
by the operator from the keyboard entry. 

B. The remaining steps in the operator initiated copy operation 
are the same as the host initiated copy request. 

C. The SCU shall notify the operator (via CRT) upon the comple- 
tion of the copy routine. The operator has already received 
the instructions as to the distribution of the master and 
copies, with the original job order. 

5.7.3 Data Quality Monitor "COPY FILENAME” Requests . It may be 
desirable, though not necessary, that subsystem monitors be 
implemented to determine the number of detected errors during a 
data transfer. This may levy additional requirements upon the 
error detection/correction circuits to provide the number of de- 
tectable errors and not just those that are uncorrectable ) - 

A usage algorithm or activity monitor may also be implemented to 
determine the number of accesses to a file. As the number of 
accesses increase, the amount of tape wear and distortion increases 
to the point of increasing error probabilities. Either of these 
types of monitors could be implemented to initiate the copy requests. 
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A. The Data Quality Monitor queues the logical request to "COPY 
FILENAME". The remaining steps in the monitor initiated 
copy operation are the same as the host initiated request. 

B. During the transfer, the copy/verify routine logs the 
number of uncorrectable errors and the block addresses of 
these errors . 

C. The SCU notifies the operator that the file transfer is 
complete and the number of uncorrectable errors, if any, 
that were indicated. 

D. The operator should then decide whether or not the copy is 
a suitable replacement for the original file. If not, the 
operator should take steps to read the file into the ori- 
ginating host to rebuild the master file. The blocks 
containing errors should be scanned and additional error 
correction techniques employed to reproduce the erroneous 
portions of the master. 
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SECTION 6 

SYSTEM DEVELOPMENT PLANS 


This section identifies those development plans that are considered' 
pertinent to the design of this system, but are not covered by the 
generic requirements and functional descriptions. 

6.1 DEVELOPMENT TIMELINE 

A requirement of the Phase II amendment to SISO EO-OOIP states that 
the system design shall be completed 'to the point of publishin'g 
the hardware and software design specifications, and conducting 
the critical design review CCDR) on or about September 1, 1976. 

To accomplish this activity, a preliminary design review (PDR) 
shall be held on or about June 15, 1976 to initiate- the detailed 
design efforts. Conceptual configuration, feasibility studies, 
and trade-off analysis a-long with some preliminary simulation 
modeling shall be 'completed prior to April 15, 1976. 

6.2 PROPOSED SYSTEM COST 

To produce a viable alternative to compete with the presently 
available On-Line Mass Storage Systems, it is a design goal that 
the system cost remain below $300,000, including a minimal staging/ 
buffering subsystem and a storage device with dual read/write 
capability. This figure is a. production run goal, not the esti- 
mated development system cost. 

6.3 IMPLEMENTATION 

The mass storage system (MSS) is to be implemented (minimal con- 
figuration) in the JSC Building 12 Central Computational Facility 
which shall serve as the test bed for the MSS performance evalua- 
tion. 

The test bed configurations shall provide the capability to demonstrate 
the operations specified in paragraph 5.1 These operations shall be 
demonstrated for the two basic configurations shown in figures 6-1 
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and 6-2. In the Data Reduction Configuration emphasis will be 
placed on the Read/Modify/Replace Data Files operation utilizing 
a single host system with dual I/O channels. The Multi-processor 
Support Configuration will primarily be used to demonstrate those 
functions relating to a multi-host processing environment. 

The test bed facility shall provide UNIVAC 1100 series host compu- 
ter systems and utilize the EXEC-8 as the host operating system. 

A software model of the mass storage system is to be developed to 
assist in performance evaluation during the feasibility studies 
and trade-off analysis. An analysis of the available modeling , 
programs and recommendations for the development of the system 
models is provided in JSC- 10167, Quadruplex Record/Reproduce Cart- 
ridge Storage Equipment 'Performance Specification. 

6.4 RELIABIL-ITY/MAINTAINABILITIf 

Reliability and maintainability support shall be provided during 
the system development cycle. This effort shall permit trade-offs 
to be conducted so the system and product reliability and maintain- 
ability can be achieved. 

Configuration analyses shall be performed on the Mass Storage 
System during the conceptual design stages. The task shall involve 
obtaining, data for the system components to maximize the availability 
of the equipment configuration. 

6.5 SYSTEM CONCEPTUAL DESIGN REVIEW 

It is intended that this document provide the basic information 
to conduct a "Conceptual" design review as an initial phase of 
the system development planning. 

To assist in this review, some trade-off studies have been con- 
ducted and their results are described in the following study 
reports . 

• JSC-10038, Mass Storage System Simulation Planning 

• JSC-10167, Quadruplex' -Record/Reproduce Cartridge Storage 
Equipment Performance Specification 
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• JSC-10039, Reliability Evaluation of the General Electric 
BEAMOS Memory 

• JSC-10040, Mass Storage System Error Rate Analysis. 
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Figure 6-2 Test-Bed Multi-Processor Support 
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